Libris Britannia 4/science library(b).zip/science library(b)/DDJMAG/DDJ9207.ZIP/WPAPER.TXT

Text File | 1992-03-31 | 15KB | 255 lines

Subject: White Paper
Date: Tue, 17 Mar 92 15:52:12 MST


TWAIN
Linking applications and images


The Issue
^^^^^^^^^
In desktop publishing's early days, most publications contained only text
and simple black-and-white line drawings that were output to black-and-white
laser printers. In recent years, however, computer hardware and software
has become much more sophisticated. Both business professionals and graphic
artists can now create and output complex, full-color publications. This
near-commercial-quality work may include black-and-white, greyscale, and
color images acquired from desktop and hand-held scanners, or from still
video, digital cameras or image capture boards. This growth in technology
means vendors are faced with a challenge: to supply customers with hardware
and software products that enhance productivity by working together
seamlessly for an efficient, easy-to-use computing process. Unfortunately,
image acquisition remains a difficult process. To acquire and place an
image in your publication, you must leave the application in which you are
working. Then you must locate and open a hardware driver, set the device
options, acquire the image, save it to disk, close the hardware driver,
return to the application, then locate and read in the image file from
disk. The process is time-consuming and tedious, and not how business
professionals, designers, or publishers want to work, particularly with
the increasing need for on-demand integration of images acquired in real
time.


The Solution
^^^^^^^^^^^^
When the image-acquisition issue surfaced, hardware and software
developers began defining their own image acquisition interfaces. This
was a step in the right direction, but it soon became apparent that high
numbers of proprietary interfaces were not the ultimate solution. It's
inefficient to require a software developer to write a driver for each
device they need to support. Conversely, it doesn't make sense to ask a
hardware vendor to write a different driver to interface with each
software application. Most importantly, it isn't acceptable that users
must deal with many unique application/device driver files.

Users need a painless way to get image data into their applications.
Software developers need compatibility with the widest range of output
devices without writing and maintaining multiple device drivers.
Hardware developers need compatibility with the greatest number of
applications without application-dependent coding.

The most obvious solution to this situation is an open industry
interface that directly acquires image data from external sources while
within an application. In this scenario, each software developer
supports a standard data acquisition manager and each hardware vendor
writes one driver for their device. Hardware vendors will benefit
because they need only provide one standard driver for their device,
which can then be used by all software applications supporting the
standard data acquisition interface. Software vendors will be freed
from writing and supporting device drivers, or from soliciting support
for their own proprietary interface. Software vendors will also benefit
because one single interface will support those vendors writing these
device drivers. Users will benefit because they can place a smaller set
of drivers at the operating system level and take advantage of seamless
images acquisition from a large number of applications.

History and structure of the TWAIN consortium
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In early 1990, the formation of the Macintosh Scanner Roundtable group
heightened the imaging industry's awareness of the need for an open
interface. While participation in the roundtable was high, it was
difficult to resolve issues and progress was slow. At one of the group's
last meetings in 1990, it was suggested that a smaller set of industry
leaders form a consortium and create a specification for review,
revision, and ultimate adoption by the imaging industry.

The TWAIN Working Group was formed with representatives from Aldus,
Caere, Eastman Kodak, Hewlett-Packard, and Logitech. The Working Group's
primary goal was defined as promoting imaging product use by developing
an integrated easy-to-use image acquisition interface and educating
users about its existence. A key requirement of participation was that
members be willing to represent a broader interest than that of their
own company. The number of participants was kept low so the
specification could be written quickly, while representation from a
wide spectrum of application developers (desktop communications and
OCR) and hardware vendors (hand-held, desktop, and high-end color
imaging devices) was maintained. The result was that working group
members represent diversity in the industry, and bring in-depth imaging
experience to both hardware and software development, and marketing
fields.

At the TWAIN Working Group's first meetings, engineers faced the huge
task of reviewing specifications and resolving outstanding requirements
issues. Most Working Group companies had written their own interface for
direct image acquisition, and these were considered, as well as more
than two dozen specifications provided by other companies. No single
specification or protocol, including those from operating system
vendors, provided the completeness, richness of functionality, and ease
of implementation that was required. Eventually, a composite of Silicon
Beach/Adobe Plug-ins, an internal Aldus protocol, an HP protocol under
development and Logitech's SAPI was used as the basis for TWAIN.

TWAIN Working Group engineers participated in monthly workshops to
define the specification. A separate Marketing Working Group meets to
discuss publishing a toolkit, supporting the interface, and other issues,
including how to inform the industry and public about the interface.

Besides the TWAIN Working Group, more than 175 major imaging hardware
and software companies form a group called the "TWAIN Coalition." This
larger group reviewed the TWAIN specification and provided feedback prior
to its release. The TWAIN Working Group took comments and suggestions
from the TWAIN Coalition, examined the costs and benefits of the
modifications, and decided which to incorporate into the specification.
Some Coalition members have completed a review of the specification and
endorse it as being technically sound and beneficial for the industry;
they are identified on an endorser's list available from any Working Group
contact. The specification is now nearing completion, and applications
and sources supporting TWAIN will soon be available.

Goals of the TWAIN Specification
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TWAIN was designed to provide a consistent, easy integration of image
data between sophisticated input devices and software applications. More
detailed Working Group goals for the specification included:

o Multiple platform support - The interface must work on the Macintosh
  and under Windows, but should also have the ability to extend to UNIX,
  OS/2 and other platforms. Use of platform-specific mechanisms should be
  kept to a minimum.
o Support for multiple devices - These include hand-held scanners,
  flatbed scanners, slide scanners, image capture boards or frame grabbers,
  digital cameras and image databases-a broad range of raster image-
  generating devices.
o Widespread acceptance - Provide an interface that is well-defined and
  enables the majority of the leading hardware and software developers to
  provide drivers for their devices or include support through their
  applications.
o Extensibility and revisability - As the industry grows, the
  specification's architecture should be extensible and able to handle
  new, unknown conditions. Revisions will be backwards-compatible with
  code written to earlier versions of the specification.
o Easy implementation - The interface and its documentation should be
  clear, well structured, well written, and intuitively designed for
  developers to learn and write the code for it.
o Longevity - While the aim is to provide a solution as quickly as
  possible, the Working Group is doing all it can to make sure the
  interface is structurally sound and encompasses all functionality
  necessary to provide a single solution for the industry that will last
  for several years, or until such time as a facility like this might be
  supported at the operating system level. It is a goal of the Working
  Group that this functionality be incorporated at the operating system
  level and be TWAIN compatible.
o Multidata Capacity - This general data interchange mechanism must be
  able to transmit data in existing standard formats and native file
  formats such as TIFF, PICT, and DIB. Furthermore, TWAIN was designed to
  easily support data type extensions outside the realm of images (such
  as text, facsimile data and vector graphics.)

Architecture
^^^^^^^^^^^^
TWAIN provides a simple, yet rich, methodology for universally connecting
TWAIN-compliant applications with TWAIN-aware devices. The model for how
applications interact with the source of input data can be described
through a four-layer protocol: the Application Layer, Protocol Layer,
Acquisition Layer and Device Layer.  The acquisition components correspond
to these layers and include the application, Source Manager, Source and
physical hardware device.  The application communicates through the Source
Manager to a Source driver which represents the physical hardware device
that generates image data.

The hardware interface element of the TWAIN architecture is the Source.
A Source is a TWAIN entity whose purpose is to get data from a hardware
device and provide it to a TWAIN-compliant application. A Source is
typically written by the hardware vendor to control their peripheral
device.   These devices are usually a physical piece of hardware, such as
a scanner, although a virtual device (such as an image database) also fits
the Source model. The device may be locally connected or remotely accessed
over a network.

The core element of this architecture is the Source Manager (SM). The
SM's primary role is to establish and manage the connections between the
application and the sources. The SM allows the user to select the desired
source, loads and unloads the selected source, and makes sure that all
calls from a particular application are correctly routed to the
appropriate source. The SM is implemented as a code resource on the
Macintosh and a Dynamically Linked Library (DLL) under Microsoft Windows.
Under Windows, there will be only one copy of the SM active in memory at
any given time. On the Mac, there will be a separate copy of the SM for
each application accessing it. When the application needs to communicate
with a Source, it calls the SM with a correctly addressed message. An
application never calls a Source directly.

Let's review how to acquire an image with TWAIN: From the application,
the user first chooses "Select Source" from the menu. "Select Source"
identifies the source device from which the image will be acquired, and
is only accessed by the user when it's necessary to switch between
multiple connected devices. "Select Source" invokes the Source Manager
and a selection dialog box appears. Once the source is selected, the
user choses "Acquire" to initiate the image acquisition process.
"Acquire" brings up the Source Manager to facilitate a process called
"capabilities negotiation." This takes place between the application
sending messages (describing the data it wants) and the Source (defining
the data it can provide). When negotiation is complete, all user
interface control is passed to the Source. The Source's user interface
allows the user to set scanning options and start the scan. The Source
passes the image data back through the Source Manager to the Application,
which allows the user to place the image in their document if they
haven't already specified its destination.

TWAIN implementation allows a high degree of flexibility. Application
developers can choose from four different levels of support, which
increase in complexity. They include Glue Code, Basic, Advanced, or
Custom Support. Source developers can decide among three support
options: Basic, Advanced, or Custom. These options give developers the
ability to either support TWAIN with minimal engineering investment, or
to use TWAIN for greater differentiation through their user interfaces
and more complete access to all their product's capabilities.

How you can become involved
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Developers: In the U.S or Canada, call 1-800-722-0379 to order the TWAIN
Toolkit.  Outside U.S. or Canada, call [phone] from your fax
machine and fax yourself document number 9154, the TWAIN Toolkit order
form.  The toolkit will contain the TWAIN specification, Source Manager,
a header file, code for a sample application and Source, as well as a
marketing guide. Developer support will be available from all Working
Group companies.

Users: Look for the TWAIN logo or name on any hardware or software you
purchase. Ask product vendors when they will be supporting TWAIN. Refer
developers to any TWAIN Working Group member listed below if they are
not yet aware of this interface. Let Working Group companies know how you
work with TWAIN, especially if you have ideas on how the interface can be
improved or extended to better meet your needs and the way you work.


TWAIN Working Group Contacts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Aldus           - Developers Desk [phone]
  Caere           - Fax Support [phone]
  Eastman Kodak   - Support Line [phone]
  Hewlett-Packard - TWAIN Support [phone]
  Logitech        - TWAIN Developer Support (510) 713-5DEV


A note on our name
^^^^^^^^^^^^^^^^^^
Some of you may have been introduced to the TWAIN interface under the
names "Direct-Connect" or "CLASP." While this effort has been promoted
under these names in the past, trademark searches turned up too many
conflicts for us to feel comfortable using either of these as the final
name. After numerous searches, we selected the name TWAIN to describe
this interface which brings together two entities, applications and
input devices, in a meeting of the "TWAIN."

/* end document */